A  CONTRIBUTION  TO  THE 
STANDARDIZATION  OF  GPS  AND  GLONASS 

TIME  TRANSFERS 


W.  Lewandowski,  J.  Azoubib 
Bureau  International  des  Poids  et  Mesures 
Pavilion  de  Breteuil,  92312  Sfevres  Cedex,  France 

A.G.  Gevorkyan,  P.P.  Bogdanov 
Russian  Institute  of  Radionavigation  and  Time 

W.J.  Klepczynski* 

ISI  Corporation 

M.  Miranian 

United  States  Naval  Observatory 

J.  Danaher 
3S  Navigation 

N.B.  Koshelyaevsky 

Russian  National  Time  and  Frequency  Service 

D.W.  Allan 
Allan’s  TIME 


Abstract 

The  international  time  metrology  community  has  already  succeeded  in  the  implementation,  in 
the  almost  all  type  of  GPS  time  receivers,  of  uniform  software  for  the  treatment  of  raw  data.  For 
the  GLONASS  and  GPSfGLONASS  time  receivers  now  arriving  on  the  market,  it  was  decided  to 
adapt,  roughly  and  for  temporary  use,  standards  devised  for  GPS.  In  this  paper  specific  problems 
for  these  two  new  type  receivers  are  identified  and  solutions  for  standards  and  format  update  are 
suggested.  The  paper  also  reports  briefly  on  international  decisions  recognizing  advantages  of  using 
of  both  systems. 

So  far,  no  standards  address  the  difficulties  experienced  with  time  receiver  hardware.  The 
best-known  hardware  problem  is  sensitivity  to  external  temperature.  This  paper  suggests  that  the 
temperature  of  antennas  be  held  constant  by  enclosing  them  in  temperature-stabilized  ovens. 

‘Formerly  with  the  United  States  Naval  Observatory. 


367 


Report  Documentation  Page 


Form  Approved 
OMB  No.  0704-0188 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 


1.  REPORT  DATE 

DEC  1996 


2.  REPORT  TYPE 


3.  DATES  COVERED 

00-00-1996  to  00-00-1996 


4.  TITLE  AND  SUBTITLE 

A  Contribution  to  the  Standardization  of  GPS  and  Glonass  Time 
Transfers 

6.  AUTHOR(S) 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

U.S.  Naval  Observatory ,3450  Massachusetts  Ave 
NW, Washington, DC, 20392 


5a.  CONTRACT  NUMBER 


5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

5d.  PROJECT  NUMBER 


5e.  TASK  NUMBER 


5f.  WORK  UNIT  NUMBER 

8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 


9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 


10.  SPONSOR/MONITOR'S  ACRONYM(S) 


11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 


12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

See  also  ADA419480.  28th  Annual  Precise  Time  and  Time  Interval  (PTTI)  Applications  and  Planning 
Meeting,  Reston,  VA,  3-5  Dec  1996 


14.  ABSTRACT 

see  report 


15.  SUBJECT  TERMS 


16.  SECURITY  CLASSIFICATION  OF: 


a.  REPORT 

unclassified 


b.  ABSTRACT 

unclassified 


c.  THIS  PAGE 

unclassified 


17.  LIMITATION  OF 

18.  NUMBER 

ABSTRACT 

OF  PAGES 

Same  as 

20 

Report  (SAR) 

19a.  NAME  OF 
RESPONSIBLE  PERSON 


Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


INTRODUCTION 


Over  a  period  of  about  15  years  the  uncertainties  quoted  for  GPS  international  time  comparisons 
have  improved,  falling  from  a  few  tens  of  nanoseconds  to  a  few  nanoseconds.  Recent  progress 
has  included  the  successful  implementation  of  standards  for  software  and  data  form  at.  M  The 
use  of  GLONASS  for  international  time  transfer  was  delayed  until  last  year  by  the  lack  of 
commercial  time  receivers.  Their  recent  appearance,  plus  knowledge  accumulated  during  a 
decade  of  GPS  practice,  allowed  rapid  progress  in  the  use  of  GLONASS  for  time  transfer.  1*1  To 
speed  up  implementation  of  the  GLONASS  common-view  technique,  some  standards  devised 
for  GPS  by  the  CGGTTSf2!  were  adapted  for  temporary  GLONASS  use.  This  comes  close  to 
fulfilling  immediate  needs,  but  must  be  considered  as  a  provisional  solution  because  it  does  not 
address  specific  GLONASS  issues  such  as  the  use  of  ionospheric  and  tropospheric  corrections, 
relativistic  corrections,  satellites  ephemerides,  antenna  coordinates,  etc.  A  new  family  of  dual¬ 
system  GPS/GLONASS  time  receivers  now  available  will  create  new  opportunities,  but  will  also 
call  for  technical  directives  to  describe  the  use  of  two  systems  in  a  single  receiver.  Considering 
the  above,  the  13th  meeting  of  the  Comite  International  pour  la  Definition  de  la  Seconde 
(CCDS)  transformed  the  CCDS  Group  on  GPS  Time  Transfer  Standards  (CGGTTS)  into  the 
CCDS  sub-Group  on  GPS  and  GLONASS  Time  Transfer  Standards  (CGGTTS).  Also,  a  CCDS 
recommendation  and  declaration  addressed  the  issue  of  common  use  of  GPS  and  GLONASS 
satellites  and  stressed  the  need  for  both  systems  to  respect  international  standards  for  time 
reference  and  reference  frames. 

This  paper  identifies  specific  software  problems  to  be  standardized  for  GLONASS  and  GPS/GLO¬ 
NASS  time  transfers  and  suggest  an  adapted  data  output  format.  Until  now  no  standards  have 
been  issued  to  address  difficulties  related  to  time  receiver  hardware.  The  best-known  hardware 
problem  is  sensitivity  to  external  temperature  and  this  paper  suggests  that  the  use  of  temperature 
stabilized  ovens  be  standardized  for  GPS  and  GLONASS  antennas  in  use  for  high  precision 
time-transfer  applications. 


BRINGING  GPS  AND  GLONASS  TOGETHER 

The  arrival  of  GLONASS  underlines  the  need  for  Global  Navigation  Satellite  Systems  to 
adopt  common  system  of  reference.  In  fact,  GPS  and  GLONASS  use  different  systems 
for  both  positioning  and  timing.  This  does  not  preclude  the  interchangeable  use  of  the 
48  satellites  composing  the  two  constellations,  but  does  complicate  it.  GPS  already  follows 
international  standards,  and  its  closeness  to  them  is  constantly  improved.  This  is  not  the  case 
for  GLONASS,  but  a  far-reaching  and  important  recommendation,  S  4  (1996),  issued  this 
year  by  two  international  committees,  the  Comite  International  des  Poids  et  Mesures  and  its 
Consultative  Committee  CCDS  PI,  specifies  a  basis  for  harmonizing  GPS,  GLONASS,  and  other 
upcoming  global  navigation  satellite  systems.  This  recommends: 

•  the  synchronization  as  close  as  possible  to  UTC  the  reference  times  of  satellite  naviga¬ 
tion  systems  with  global  coverage  (including  GPS,  GLONASS,  INMARSAT,  GNSS1,  and 
GNSS2), 

•  the  transformation  of  reference  frames  of  these  systems  to  be  in  conformity  with  the 
terrestrial  reference  frame  (ITRF)  maintained  by  the  International  Earth  Rotation  Service, 

•  the  use  of  both  GPS  and  GLONASS  receivers  at  timing  centers. 
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The  recommendation  does  not  make  GLONASS  depend  on  GPS  or  GPS  on  GLONASS,  but 
requests  that  both  systems  follow  internationally  recognized  standards  for  time  and  space.  Given 
the  increasing  importance  of  civil  applications,  the  Russian  authorities  are  likely  to  consider 
more  strict  application  of  international  standards  to  GLONASS.  M 

Also,  the  Executive  Board  of  the  United  States  Civil  GPS  Service  Interface  Committee  (CGSIC), 
which  is  a  forum  for  the  exchange  of  GPS  information  between  military  and  civilian  elements, 
has  recognized  that  the  common  use  of  GPS  and  GLONASS  for  civil  applications  is  a  very 
positive  development.  The  CGSIC  Executive  Board  is,  however,  well  aware  that  the  two 
systems  use  different  references  for  timing  and  positioning,  and  fully  supports  the  above  named 
recommendation.  The  similar  questions  civil  GLONASS  users  would  like  to  bring  to  the 
attention  of  GLONASS  authorities.  However,  the  absence  in  Russia  of  a  body  similar  to 
CGSIC  nowadays  limits  interaction  between  civil  users  and  military  holders  of  GLONASS. 
Some  Russian  experts  consider  that  Information  Center  of  Russian  Space  Forces,  so  called 
CSIC  (Coordinational  Scientific  Information  Center),  should  play  such  a  role. 

The  same  CCDS  meeting  issued  a  declaration!^  which  asks  the  CGGTTS: 

•  to  contact  manufacturers  of  receivers  and  request  them  to  adapt  their  systems,  both  in 
hardware  and  software,  to  the  time  and  frequency  laboratory  requirements  so  that  these 
receivers  can,  for  example,  record  signals  of  GPS  and  GLONASS  satellites  in  the  dual 
frequency  mode,  in  multichannels,  in  a  data  format  defined  by  the  group,  have  internal 
calibration,  and  be  as  far  as  possible  insensitive  to  environmental  conditions, 

•  to  maintain  these  contacts  and  keep  time  and  frequency  laboratories  informed  of  their 
actions  and  of  the  specific  and  operational  advantages  of  unifying  these  receivers. 


REFERENCE  FRAMES 

It  is  now  general  practice  for  laboratories  engaged  in  accurate  GPS  time  transfer  to  express 
ground-antenna  coordinates  with  decimetric  uncertainties  in  the  ITRF,  the  internationally 
recognized  ultra-accurate  terrestrial  reference  frame.  Postprocessed  GPS  precise  ephemerides 
are  also  expressed  in  the  ITRF.  Although  actual  GPS  broadcast  ephemerides  are  expressed  in 
the  WGS  84,  the  newest  realization  of  this  reference  frame  agrees  to  within  one  decimeter  with 
the  ITRF.  Also,  because  standards  established  by  the  CGGTTS  have  now  been  implemented, 
it  is  possible  to  introduce  antenna  coordinates  expressed  in  the  x,y,z  Cartesian  form  into  GPS 
time  receivers.  This  avoids  the  transformation  of  geodetic  coordinates  into  Cartesian  form, 
a  transformation  which  was  necessary  in  previous  types  of  GPS  time  receiver  and  created  a 
possible  source  of  errors.  To  sum  up:  the  use  of  coordinate  reference  frames  for  GPS  time 
transfer  is  well  defined,  well  practiced,  and  fulfills  all  recommendations  and  standards. 

The  situation  is  somewhat  different  for  GLONASS.  Its  geodetic  reference  frame  PZ-90  can  differ 
by  up  to  20  m  from  ITRF  on  the  surface  of  earth  and  no  accurate  relationship  between  PZ-90 
and  ITRF  is  yet  known. I5-*!  The  simplest  way  to  determine  GLONASS  antenna  coordinates  is  to 
average  a  series  of  navigation  solutions.  But  the  uncertainties  of  such  coordinates  are  no  better 
than  several  meters  and  can  have  an  impact  on  the  accuracy  of  the  common-view  link  of  a  few 
tens  of  nanoseconds.  First  users  of  GLONASS  time  receivers  decided  ad  hoc  to  determine  the 
GLONASS  ground-antenna  coordinates  in  the  ITRF  wherever  this  was  possible.  This  has  the 
obvious  advantage  of  immediately  providing  the  best  possible  consistency  of  antenna  coordinates 
between  various  sites.  At  present  the  ITRF  antenna  coordinates  introduced  into  R-100-type 
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receivers  are  transformed  to  the  PZ-90  reference  frame  to  make  them  consistent  with  broadcast 
ephemerides.  All  R- 100-type  receivers  now  in  operation  use  the  same  transformation  formulae 
and  parameters.  If  this  practice  is  retained,  a  set  of  standard  parmeters  should  be  adopted 
and  recorded  in  the  file  header;  detailed  changes  are  noted  in  Annex  I. 

In  order  to  harmonize  GLONASS  with  GPS  and  avoid  operations  on  ultra-precise  ITRF 
coordinates,  another  approach  would  be  to  keep  the  ITRF  coordinates  unchanged  in  the  receiver 
and  transform  broadcast  ephemerides  from  PZ-90  into  ITRF  according  to  a  standardized  set 
of  formulae  and  parameters.  These  parameters  would  be  recorded  in  the  file  header;  detailed 
changes  are  noted  in  Annex  I. 

We  should  also  expect  that  future  GLONASS  postprocessed  precise  ephemerides  will  be 
expressed  in  ITRF  coordinates. 


TIME  REFERENCES 

For  time  reference,  GPS  relies  for  its  ‘GPS  time’  on  UTC(USNO),  Coordinated  Universal  Time 
(UTC)  as  realized  by  the  USNO.  GLONASS  relies  for  its  ‘GLONASS  time’  on  UTC(SU),  UTC 
as  realized  by  the  Russian  Federation.  UTC  is  produced  by  the  BIPM  and  is  the  internationally 
recognized  time  reference  for  the  whole  earth.  The  deviation  of  UTC(USNO)  from  the  UTC 
generally  remains  within  20  ns.  This  closeness  of  approach  is  attributed  to  the  50  or  so 
cesium  atomic-beam  clocks  and  15  or  so  active-cavity  hydrogen  masers  that  form  the  USNO 
ensemble.  In  the  Russian  Federation,  however,  UTC(SU),  which  is  derived  from  an  ensemble 
of  active-cavity  hydrogen  masers,  is  drifting  from  UTC.  The  deviation,  [UTC  -  UTC(SU)] 
was  approaching  -8,000  ns  in  October  1996  (Fig.  1).  Following  the  recommendation  described 
above,  however,  the  Russian  authorities  have,  with  effect  27  November  1996,  brought  the 
UTC(SU)  into  close  alignment  with  UTC  by  applying  a  time  step  of  9,000  ns.  The  GLONASS 
Control  System  Center,  which  carries  out  the  GLONASS  operation,  has  been  notified  of  this 
change,  and  it  seems  likely  that  GLONASS  time  will  not  be  corrected. 

The  GPS  operators  keep  GPS  time  within  100  ns  (modulo  1  s)  of  UTC(USNO),  and  the 
actual  value  is  generally  much  better  than  this.  There  have  been  a  few  exceptions,  as  in  a 
period  of  about  two  weeks  in  December  1994  when,  due  to  a  malfunction,  GPS  time  made  an 
excursion  from  UTC(USNO)  of  about  270  ns  (Fig.  2).  But  GPS  broadcast  a  time  correction 
allowing  users  to  access  UTC(USNO)  with  an  uncertainty  of  100  ns.  This  shows  that  the  use 
of  broadcast  UTC(USNO)  might  be  safer  for  some  applications,  as  GPS  time  can  always  be 
subject  to  some  anomaly. 

For  GLONASS,  the  difference  between  GLONASS  Time  and  UTC  in  October  1996  was  around 
30,000  ns,  and  it  is  steadily  drifting  (Fig.  1).  According  to  GLONASS  ICD,  the  offset  between 
GLONASS  time  and  UTC(SU)  should  not  exceed  1  millisecond.  GLONASS  does  broadcast  a 
time  correction  allowing  users  to  access  UTC(SU)  with  an  uncertainty  of  1,000  ns. 

The  differences  between  GPS  time,  GLONASS  time,  and  UTC(SU)  pointed  above  do  not  affect 
common-view  time  transfer,  as  readings  of  satellite  clock  vanish  in  the  difference.  This  has 
only  an  effect  during  a  common  navigation  solution  from  GPS  and  GLONASS.  A  single  system 
navigation  solution  requires  four  satellites  to  determine  four  unknowns:  position,  x,y,z,  and 
the  user’s  clock  bias.  Present  differences  between  GPS  time  and  GLONASS  time  mean  that  a 
dual-system  GPS/GLONASS  navigation  solution  requires  five  satellites  to  determine  position, 
x,y,z,  the  user’s  clock  bias,  and  the  clock  offset  between  the  two  system  times. 

Reported  in  Fig.  1  are  values  of  [UTC  -  GLONASS  time ]  which  were  published  in  BIPM 
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Circular  T  according  to  observations  performed  at  University  of  Leeds  with  a  GPS/GLONASS 
receiver  designed  and  built  in-house.  The  same  differences,  derived  from  GLONASS  observation 
at  the  BIPM  with  a  R-100/10  receiver,  differ  by  a  constant  of  about  1,250  ns.  See  the  table 


UTC”  GLONASS  time 

Date  1995 

by  Circ.  T 
(ns) 

Dy^<-l00/10” 

(ns) 

Circ.  T  -  R-100/10 
(ns) 

Aug  10 

-19812 

-21055 

1243 

Aug  20 

-20188 

-21421 

1233 

Aug  30 

-20549 

-21813 

1264 

We  know  that  R-100  receivers  are  not  calibrated  absolutely.  Similar  differences  were  observed 
using  other  R-100  receivers  at  the  VSL  and  the  DLR.t7’*!  We  prefer  to  trust  the  Leeds  values, 
because  there  the  primary  observations  are  [GPS  time  ~  GLONASS  time].  The  hardware 
delay  is  probably  the  same  for  GPS  and  GLONASS  signals  and  should  cancel  in  the  difference. 

Data  from  similar  comparison  with  GLONASS  data  recorded  with  the  Russian  ASN-16-02 
GLONASS  receiver  at  the  National  Time  and  Frequency  Service  VNIIFTRI  near  Moscow  are 
reported  below. _ _ _  _ 


UTC-7  GLONASS  time 

Date  1996 

by  Circ.  T 
(ns) 

by  “ASN-16-02 
(ns) 

(ns) 

July  30 

-30591 

-30808 

r  2T7 

Aug  04 

-30744 

-30923 

179 

Aug  09 

-30868 

-31071 

203 

Aug  14 

-31002 

-31200 

198 

Aug  19 

-31135 

-31323 

188 

Aug  24 

-31258 

-31459 

201 

Here,  we  observe  better  agreement  with  the  results  from  Leeds  University  published  in  Circular 
T,  but  it  must  be  remembered  that  Russian  receivers  are  also  not  absolutely  calibrated  and  so 
do  not  provide  an  independent  check. 

Summing  up,  we  note  that,  because  GLONASS  receivers  are  not  calibrated  absolutely,  we  know 
[UTC  -  GLONASS  time]  with  an  accuracy  no  better  that  1  microsecond.  GPS  receivers 
are  absolutely  calibrated  and  [UTC  -  GPS  time]  is  known  with  an  accuracy  of  a  few  tens  of 
nanoseconds.  GLONASS  provides  worldwide  real-time  dissemination  of  UTC,  as  produced  by 
the  BIPM,  to  an  average  user  with  uncertainty  of  about  2  microseconds  after  recent  improvement 
of  the  synchronization  between  UTC(SU)  and  UTC.  GPS  does  the  same  with  uncertainty  of 
about  100  ns. 


RECEIVER  SOFTWARE 

During  a  series  of  meetings  at  the  beginning  of  1990,  the  CCDS  Group  on  GPS  Time  Transfer 
Standards  developed  a  document  called  Technical  Directives  for  Standardization  of  GPS 
Time  Receiver  Software.^  This  document  lists  nine  explicit  directives  for  the  standardization 
of  software  for  single-frequency  C/A-Code  GPS  time  receivers,  possibly  operating  in  tandem 
with  an  ionospheric  measurement  system.  These  directives  have  since  been  implemented  in 
most  GPS  time  receivers.  This  has  had  immediate  consequences  through  improvement  of  the 
accuracy  and  precision  of  GPS  time  links. 
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Since  that  time,  some  major  developments  in  timing  equipment  have  taken  place.  These 
are  mainly  the  arrival  in  1994  and  1995  of  one-channel  GLONASS  C/A-CodeI9l  and  P-Code 
time  receivers,  and  double-system  multichannel  GPS(C/A-Code)/GLONASS(P-Code)I2l  time 
receivers.  To  allow  rapid  development  of  these  receivers  it  was  decided  to  adapt,  roughly  and 
for  temporaiy  use,  some  standards  devised  for  GPS  by  the  CGGTTS.  There  is  a  consequent 
need  to  extend  more  rigorously  and  formally  the  technical  directives  to  the  needs  of  these  new 
devices  which  is  reflected  in  the  decisions  of  the  most  recent  CCDS  meeting. 

Below  we  describe  suggested  updates.  GPS  Technical  Directives  1  to  4  and  6  to  9,  and  Annex 
I  can  be  applied  strictly  to  GLONASS  data.  Directive  5,  Annex  II,  and  Annex  III,  should  be 
updated  for  GLONASS. 

Comments  on  the  adoption  of  GPS  Technical  Directive  5  for  GLONASS: 

GPS  Technical  Directive  5  requires  that  all  modelled  procedures,  parameters,  and  constants 
needed  in  short-term  data  processing  are  deduced  from  the  information  given  in  the  Interface 
Control  Document  (ICD)  of  the  U.S.  Department  of  Defense  or  in  the  NATO  Standardization 
Agreement  (STANAG).  These  are  updated  at  each  new  issue.  The  GLONASS  ICD  does 
not  include  algorithms  for  the  calculation  of  tropospheric  and  ionospheric  corrections,  nor 
does  GLONASS  broadcast  ionospheric  parameters.  It  is  suggested,  therefore,  that  in  order 
to  simplify  common  use  of  GPS  and  GLONASS  for  time  transfer,  that  for  GLONASS  the 
same  formulae  for  modelled  tropospheric  and  ionospheric  corrections  be  adopted  as  are  used 
for  GPS.  However,  the  ionospheric  correction  for  GLONASS  should  take  into  account  the 
different  GLONASS  frequencies.  In  the  case  of  dual-system  GPS/GLONASS  receivers,  GPS 
broadcast  ionospheric  parameters  should  be  applied  to  GLONASS  ionospheric  correction.  For 
single-system  GLONASS  receivers,  a  set  of  adapted  fixed  parameters  must  be  standardized.  It 
has  been  verified  experimentally  that  the  use  of  fixed  ionospheric  parameters  does  not  normally 
cause  a  deterioration  of  GLONASS  data.  This,  however,  cannot  be  true  during  strong  solar 
activity. 

Comments  on  the  adoption  of  Annex  II  for  GLONASS: 

In  GLONASS,  as  in  GPS,  the  constant  part  of  the  relativistic  correction  to  the  frequency, 
consisting  of  the  gravitational  red  shift  and  the  second-order  Doppler  effect,  is  applied  before 
launch  to  the  satellite  oscillators  as  a  frequency  offset  (4.36x10" 10  for  GLONASS).  Periodic 
relativistic  corrections  to  take  account  of  the  eccentricity  of  the  GLONASS  satellite’s  orbit  are 
applied  when  generating  time  and  frequency  corrections  to  the  offset  between  satellite  time 
and  GLONASS  time.  These  are  uploaded  to  the  satellite  and  transmitted  in  the  navigation 
message.  This  implies  that  point  (iii-5)  of  Annex  II  should  not  be  applied  to  GLONASS  data. 

Most  of  the  solutions  suggested  above  are  already  applied  to  3S  Navigation-type  receivers.  On 
one  point  these  receivers  do  not  follow  Technical  Directive  9.  This  Directive  requires  that,  for 
multichannel  receivers,  one  data  file  should  be  created  for  each  channel.  3S  receivers  put  data 
from  all  channels  and  from  two  systems  into  one  file.  In  practice,  this  way  of  handling  data 
has  proved  to  be  very  convenient  and  it  is  suggested  that  Directive  9  be  changed  to  standardize 
the  use  of  one  file. 

Suggested  update  of  Annex  III  GGTTS  GPS  Data  Format  Version  01  of  Technical 
Directives  is  described  in  Annex  I  of  this  paper. 
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TEMPERATURE  SENSITIVITY 


It  is  now  well  documented  and  generally  admitted  that  GPS  time  equipment  is  sensitive  to 
external  temperature.  This  sensitivity  ranges  from  about  0.2  ns/°C  to  2  ns/°C.  Even  for  the 
lower  value,  the  delay  change  can  be  the  dominant  contribution  to  the  noise  of  time  transfer 
by  common  view  for  periods  of  several  days  over  short  baselines  of  several  hundred  kilometers. 
The  larger  value  makes  it  the  dominant  contributor  to  the  noise  of  common-view  time  transfer 
even  for  intercontinental  baselines.  We  illustrate  this  phenomenon  for  GPS  equipment  with  the 
latest  results  recorded  during  calibration  of  a  GPS  reference  receiver  at  the  USNO  covering  a 
period  of  11  months  (Fig.  3).  For  GLONASS  we  the  report  the  first  ever  comparison  of  two 
GLONASS  time  receivers  recorded  at  the  BIPM  during  a  period  of  10  months  (Fig.  5). 

It  can  be  seen  that  the  GPS  and  GLONASS  receivers  have  similar  behavior  both  over  periods 
of  several  days  and  for  the  full  period  of  comparison.  Short  periods  are  characterized  by  the 
correlation  with  external  temperature  (Fig.  4  and  Fig.  6).  A  rough  estimate  of  the  correlation 
coefficient  is  0.2  ns/°C  for  both  GPS  and  GLONASS.  No  seasonal  effect  is  evident. 

The  modified  Allan  deviation  shows  white  phase  noise  for  periods  of  several  months.  This 
makes  possible  to  average  differences  between  two  pairs  of  receivers  for  the  whole  duration  of 
comparison.  Corresponding  standard  deviation  is  2.5  ns  for  GPS  and  4.0  ns  for  GLONASS.  The 
larger  value  for  GLONASS  is  attributed  to  the  somewhat  noisier  results  obtained  from  the  of 
R-100/10  receiver,  which  were  estimated  by  common-view  comparisons  with  other  laboratories.  PI 
We  omit  here  the  constant  differences  between  the  receivers,  which  are  not  of  interest  for  this 
presentation. 

The  sensitivity  to  external  temperature  suggests  an  effect  linked  to  the  parts  of  time  equipment 
located  in  the  open  air,  that  is  to  the  antenna  and  its  cable.  The  receiver  itself  is  usually 
located  in  an  air-conditioned  room.  For  several  years  different  hypotheses  were  considered 
to  explain  the  temperature  dependence  of  timing  equipment.  All  linked  the  problem  to  the 
electronics  of  the  antenna,  but  none  were  verified  and  proved.  Experiments  showed  that  the 
changes  were  not  due  to  the  changes  in  antenna  cablet10!,  however  length  and  material  of  the 
cables  are  important  and  must  be  considered. 

As  no  practical  way  was  found  to  resolve  the  problem  electronically,  another  approach  was 
suggested:  the  antenna  should  be  protected  by  an  oven  with  stabilized  temperature.!11!  The 
temperature  of  the  oven  used  at  the  BIPM  was  set  at  38°C.  Initial  observations  show  that 
temperature  stabilization  of  the  antenna  assembly  appears  to  reduce  or  even  eliminate  diurnal 
delay  variation.  It  is  thought  that  this  is  due  to  stabilization  of  the  temperature  of  the  filters  and 
amplifiers  rather  than  the  antenna  element  itself.  Thus,  it  is  possible  to  make  the  preliminary 
recommendation  that  GPS,  GLONASS,  and  GPS/GLONASS  antenna  electronics  and  outdoor 
in-line  amplifiers  be  temperature  stabilized  when  they  are  used  for  precision  time  applications. 
Further  studies  will  be  performed  to  further  confirm  this  recommendation. 

However,  the  development  of  a  built-in  calibration  system  for  time  receivers  is  a  challenge  for 
timing  community.  This  solution  is  the  most  adapted  to  resolve  present  difficulties  with  delay 
stablility  of  GPS  and  GLONASS  time  equipment. 


NEW  DEVELOPMENTS 

The  accuracy  of  the  GPS  and  GLONASS  common-view  time  transfer  could  be  improved  by 
changing  common  practice  in  making  common  view  observations.  This  section  describes  some 
of  the  suggestions  that  are  likely  to  ultimately  result  in  a  considerable  improvement  in  the 
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accuracy  of  common-view  time  observations.  Typical  practice  in  making  common-view  time 
observations  is  for  all  receivers  in  an  area  to  track  a  single  satellite  for  780  seconds  according 
to  the  schedule  published  by  the  BIPM.  The  time  difference  between  the  local  reference  clock 
and  the  GPS  or  GLONASS  constellation  time  is  computed  by  an  agreed  real-time  algorithm 
and  these  data  are  output  to  a  text-editable  file.  There  is  then  a  delay  of  180  seconds  until 
the  start  of  the  next  tracking  period. 

The  method  of  single  satellite  observation  over  a  780-second  integration  period  results  largely 
from  the  receiver  tracking  channel,  memory  size,  and  data  communication  bandwidth  limitations 
that  existed  at  the  time  this  technique  was  developed.  The  real-time  algorithm  fits  a  straight 
line  to  short-term  effects,  such  as  multipath  and  atmospheric  path  delay  variations,  that  would 
probably  be  amenable  to  more  sophisticated  processing  algorithms  if  a  more  complete  data 
set  were  available.  Observations  based  on  simultaneous  observation  of  several  satellites  may 
yield  an  improvement  of  time-transfer  accuracy  in  rough  proportion  to  the  square  root  of  the 
number  of  satellites  tracked. 

For  this  reason  it  suggested  that  common-view  observations  be  made  continuously  and  more 
often,  and  that  all  satellites  in  view  (e.g.  all-in-view)  be  observed.  This  can  be  done  with 
multichannel  receivers.  The  laboratories  already  equipped  with  such  receivers  could  start 
experimentally  to  record  all-in-view  observations  according  to  three  possible  schemes: 

•  with  classical  780-second  integration  periods, 

•  with  15-second  integration  periods, 

•  at  a  rate  of  1  per  second;  some  laboratories  already  use  this  approach,  known  as  Advanced 
Common  View  (ACS),  on  experimental  basis.!12! 


Existing  time-transfer  receivers  typically  discard  carrier  phase  and  pseudo-range  data  after  the 
time-transfer  algorithm  is  executed.  If  these  data  are  retained,  it  is  likely  that  postprocessing 
with  more  complete  orbital  data  and  more  sophisticated  algorithms  will  lead  to  a  more  accurate 
time-transfer  result.  Already  several  trials  have  shown  the  advantages  of  using  carrier  phase 
measurements  for  frequency  comparisons.l13-14l  The  Receiver  Independent  Exchange  Format 
(RINEX)!15*  provides  a  convenient  format  for  recording  GPS  and  GLONASS  carrier  phase 
and  pseudo-range  data.  If  the  receiver  has  the  capability,  it  is  suggested  that  a  RINEX  format 
carrier  phase  and  pseudo-range  data  file  be  generated  at  15-second  intervals  for  all  satellites  in 
view.  This  data  file  can  then  be  used  for  postprocessing  of  precision  time  and  frequency  data. 


CONCLUSIONS 

1)  The  use  of  a  common  format,  standard  formulae,  and  parameters  would  simplify  worldwide 
time  dissemination  and  time  transfer  by  GPS  and  GLONASS. 

2)  Because  there  are  no  official  formulae  for  several  of  the  corrections  required  for  GLONASS 
time  transfer,  it  is  suggested  that  the  formulae  adopted  for  GPS  be  used  wherever  this  is 
possible. 

3)  It  is  suggested  that  a  single  output  file  be  used  for  multichannel  GPS  and  GLONASS  time 
observations. 

4)  It  is  suggested  that,  if  the  receiver  has  the  capability,  it  should  record  in  RINEX  format, 
in  a  separate  file,  carrier  phase  and  pseudo-range  data  generated  at  15-second  intervals  for 
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all  satellites  in  view.  It  is  recommended  that  the  15-second  carrier  phase  and  pseudo-range 
data  be  computed  using  the  15-second  pseudo-range  quadratic  fit  method  given  in  Annex  1 
and  Annex  II  of  the  Technical  Directives  for  Standardization  of  GPS  Time  Receiver 
Software^  1 

5)  It  is  suggested  that  the  ground  antenna  coordinates  of  GLONASS  time  receivers  be  expressed 
in  the  ITRF  in  Cartesian  x,y\x  form,  and  then  transformed  into  PZ-90  using  standard  formulae 
and  parameters  adopted  by  all  manufacturers. 

Another  suggested  approach  is  to  keep  the  ITRF  coordinates  unchanged  in  the  receiver,  and 
transform  broadcast  ephemerides  from  PZ-90  into  ITRF  according  to  a  standardized  set  of 
formulae  and  parameters. 

6)  The  time  difference  [UTC  -  GLONASS  time]  is  known  with  an  accuracy  of  about  1 
microsecond,  a  poor  value  which  results  from  the  absence  of  absolutely  calibrated  GLONASS 
receivers.  Such  calibration  is  becoming  urgent. 

7)  It  is  suggested  that  antennas  electronic  assemblies  and  any  outdoor  in-line  amplifiers  be 
temperature-stabilized.  The  use  of  temperature-stabilized  enclosures  should  improve  not  only 
common-view  time  transfer  and  time  dissemination,  but  also  frequency  comparisons  by  phase 
measurements. 

8)  The  development  of  a  built-in  time  calibration  system  for  time  receivers  is  a  challenge  for 
the  timing  community.  This  solution  is  the  most  adapted  to  resolve  present  difficulties  with 
delay  stability  of  GPS  and  GLONASS  time  equipment. 

9)  Appearance  of  multichannel  time  receivers  raise  the  question  of  replacing  the  present  mode 
of  scheduled  common-view  observations  by  “all  satellites-in-view”  common-view  observations. 
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Figure  1:  Deviation  of  UTC(USNO),  UTC(SU),  GPS  time  (modulo  1  s)  and  GLONASS 
time  from  UTC  from  2  January  1993  to  28  Ocober  1996. 

UTC  -  time  scale  (i) 


w  150 

C 


8  ioo 


it  50 


2-01-93 


1-01-94 


1-01-95 


1-C1-96  23-08-96 


Figure  2:  Expansion  of  Figure  5  highlighting  the  270  nanosecond  excursion  of  GPS  time 
from  UTC  (modulo  1  s)  at  the  end  of  1 994.  377 


Figure  3.  Daily  averages  of  [UTCfUSNO)  -  GPS  time]  by  TTR6  -  [UTCfUSNO)  -  GPS 
time]  by  Stel502,  and  daily  average  temperature  at  USNO  for  a  period  of  1 1  months. 


Figure  4.  Daily  averages  of  [UTCfUSNO)  -  GPS  time]  by  TTR6  -  [UTCfUSNO)  -  GPS 
time ]  by  Stel502,  and  daily  average  temperature  at  USNO  for  a  period  of  about  1  month. 
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Figure  6.  Daily  averages  of  [BIPM clock-  GLONASS  time]  by  R- 100/10  -  [BIPM clock 
GLONASS  time]  by  R- 100/30,  and  daily  average  temperature  at  BIPM  for  a  period  of 
about  1  month. 
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ANNEX  I 

A  Suggested  GPS  Format  Update  for  GPS/GLONASS 

This  is  a  suggested  update  of  the  CGGTTS  GPS  Data  Format  Version  Of  as  published  in  [1], 
for  GPS/GLONASS,  with  suggested  name  CGGTTS  GPS/GLONASS  Data  Format  Version  02. 
Adopted  notations  are  the  same  as  for  Version  01. 

1.  File  header 

Line  1-3:  same  as  Version  01. 

Line  4:  “CH*  =  •”  NUMBER  OF  CHANNELS 

Number  of  receiver  channels  separately  for  GPS  and  GLONASS. 

As  many  columns  as  necessary. 

Line  5-6:  same  as  Version  01. 

Line  7-9:  same  as  Version  01,  but  “GPS  antenna”  should  be  replaced  by  “GPS/GLONASS 
antenna” 

Line  10:  Designation  of  the  reference  frames,  and  if  necessary  transformation  parameters 
between  GLONASS  and  GPS  frames. 

As  many  columns  as  necessary. 

Line  11:  same  as  Version  01. 

Line  12:  “INT*DLY*  -  *”  INTERNAL  DELAY  “*ns*(GPS),”  INTERNAL  DELAY 
“*ns*(GLO>” 

Internal  delays  entered  in  the  receiver  separately  for  GPS  and  GLONASS,  in  ns  and 
given  with  1  decimal. 

As  many  columns  as  necessary. 

Line  13:  “CAB'DLY*  »  *”  CABLE  DELAY  “*ns*(GPS),”  CABLE  DELAY  “*ns*(GLO)” 
Delays  from  the  antenna  to  the  main  unit  including  delays  in  the  antenna  element,  filters, 
electronics  and  cable  length,  entered  in  the  receiver  separately  for  GPS  and  GLONASS, 
in  ns  and  given  with  1  decimal. 

As  many  columns  as  necessary. 

Line  14-17:  same  as  Version  01. 

2.  Line  header 

2.1  No  measured  ionospheric  delays  available 

For  no  ionospheric  measurements  available  line  header  update  is  as  follows: 

Line  18.1:  “SAT*CL**MJD%*STriME*TRKL*ELV*AZTH***REFSV****"SRSV***** 
REFSYS****SRSYS**DSG*IOE*MDTR*SMDT*MDIO*SMDI*FR*HC*FRC*CK” 
The  acronyms  are  explained  in  Section  4  below.  113  columns. 

2.2  Measured  ionospheric  delays  available 

With  ionospheric  measurements  available  line  header  update  is  as  follows: 

Line  18.2:  “SAT*CL**MJD"STTIME*TRKL*ELV*AZTH***REFSV******SRSV***** 
REFSYS****SRSYS**DSG*IOE*MDTR*SMDT*MDIO*SMDI*MSIO*SMSI*ISG* 
FR*HC*FRC*CK” 
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The  acronyms  are  explained  in  Section  4  below.  127  columns. 

3.  Unit  header 
Same  as  Version  01. 

4.  Data  line 

Line  20,  columns  1-3:  “123”  SAT  GPS  or  GLONASS  satellite  identification  number. 

a.  GPS  satellite  PRN  number,  1  to  38.  No  unit. 

b.  GLONASS  almanac  slot  number  plus  100,  101  to  124.  No  unit. 

Line  20,  columns  4-53:  same  as  Version  01. 

Line  20,  columns  54-64:  “+ 1234567890”  REFSYS 

Title  changed  from  “  REFGPS”  to  indicate  reference  to  either  constellation. 

Data  content  same  as  Version  01. 

Line  20,  column  65:  same  as  Version  01. 

Line  20,  columns  66-71:  “  + 12345”  SRSYS 

Title  changed  from  “  SRGPS”  to  indicate  slope  for  either  constellation. 

Data  content  same  as  Version  01. 

Line  20,  columns  72-101:  same  as  Version  01. 

4-1  No  measured  ionospheric  delays  available. 

Line  20,  columns  102-103:  “12”  FR 

GLONASS  transmission  frequency  channel  number.  1  to  24.  For  GPS  set  to  0.  No 
unit. 

Line  20,  column  104:  space,  ASCII  value  20  (hexadecimal). 

Line  20,  columns  105-106:  “12”  HC 

Receiver  hardware  channel  number.  0  to  99.  No  unit. 

Line  20,  column  107:  space,  ASCII  value  20  (hexadecimal). 

Line  20,  columns  108-110:  “123”  FRC 

Frequency  and  Code  type  used  for  pseudo-range  measurement,  where: 

L1C  -  LI  C/A  code, 

LIP  -  LI  P  code, 

L2C  -  L2  C/A  code  (GLONASS  future  capability), 

L2P  -  L2  P  code. 

Line  20,  column  111:  space,  ASCII  value  20  (hexadecimal). 

Line  20,  columns  112-113:  “12”  CK 

Data  line  check-sum  for  columns  1  to  111.  Check-sum  algorithm  as  defined  for  Version 

01. 

Line  20,  columns  114-140:  “123456789012345678901234567” 

Optional  comments  on  the  data  line,  constituted  of  characters  which  are  not  included  in 
the  line  check-sum  CK. 

4-2  Measured  ionospheric  delays  available 
Line  20,  columns  102-115:  same  as  Version  01. 
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Line  20,  columns  116-117:  “12”  FR 

GLONASS  transmission  frequency  channel  number.  1  to  24.  For  GPS  set  to  0.  No 
unit. 

Line  20,  column  118:  space,  ASCII  value  20  (hexadecimal). 

Line  20,  columns  119-120:  "12”  HC 

Receiver  hardware  channel  number.  0  to  99.  No  unit. 

Line  20,  column  121:  space,  ASCII  value  20  (hexadecimal). 

Line  20,  columns  122-124:  “123”  FRC 

Frequency  and  Code  type  used  for  pseudo-range  measurement,  where: 

L1C  -  LI  OA  code, 

LIP  -  LI  P  code, 

L2C  -  L2  QA  code  (GLONASS  future  capability), 

L2P  -  L2  P  code. 

Line  20,  column  125:  space,  ASCII  value  20  (hexadecimal). 

Line  20,  columns  126-127:  “12”  CK 

Data  line  check-sum  for  columns  1  to  125.  Check-sum  algorithm  as  defined 

01. 

Line  20,  columns  128-140:  “1234567890123” 

Optional  comments  on  the  data  line,  constitued  of  characters  which  are  not 
the  line  check-sum  CK. 


for  Version 


included  in 
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5.  Example  of  Proposed  Standard  Format  (fictitious  data) 

5.1  No  measured  ionospheric  delays  available,  separate  reference  frames  for  GPS  and  GLONASS 

C3GTTS  GPS /GLONASS  DATA  FORMAT  VERSION  =  02 
REV  DATE  =  1996-10-20 

RCVR  =  33  Navigation,  R-100/10  LI  GLONASS  2  CH,  S/N  00102  Rev  002  1996-10-20 
Cfl  =  1  (GPS)  ,  1  (GLONASS) 

IMS  =  99999 
LAB  =  3S 

X  =  -2473157.78  m  (GPS),  -2473171.90  m  (GLONASS) 

Y  =  -4706094.09  m  (GPS),  -4706086.67  m  (GLONASS) 

Z  =  +3512042.48  m  (GPS),  +3512038.48  m  (GLONASS) 

FRAME  m  ITRF  for  GPS,  PZ-90  for  GLONASS 
COMMENTS  =  NO  COMMENTS 

INT  DLY  *  1366.0  ns  (GPS),  1312.0  ns  (GLONASS) 

CAB  DLY  =  100.0  ns  (GPS),  105.0  ns  (GLONASS) 

REF  DLY  =  30.0  ns 
REF  =  3S 
dtSOM  -  FE 


SAT 

CL 

MJD 

STTIME 

TRXL 

ELV 

AZTH 

REF3V 

SRSV 

REFSYS 

SRSYS 

DBG 

lOE 

MDTR 

SMDT 

MDIO  SMD1 

FR 

HC 

FRC 

CK 

hharass 

s 

ldg 

.ldg 

.  Ins 

.  lps/s 

.  Ins 

■  lps/s 

.  Ins 

.Ins. 

lps/s 

. Ins .lps/s 

107 

34 

50367 

231000 

780 

273 

3287 

+903734 

+114 

+1906 

+69 

41 

9 

177 

-46 

218  -34 

21 

1 

L1C 

Cl 

107 

34 

50367 

232300 

180 

273 

3287 

+903764 

+105 

+1936 

+60 

42 

9 

156 

-33 

201  -30 

21 

1 

L1C 

B9 

9 

IB 

50367 

232600 

780 

428 

2719 

+491057 

-63 

+2120 

-72 

29 

9 

119 

-8 

174  -16 

0 

0 

L1C 

4A 

107 

18 

50367 

232600 

760 

348 

3257 

+903854 

+87 

+1926 

+41 

42 

9 

142 

-27 

188  -28 

21 

1 

L1C 

BF 

5.2  Measured  ionospheric  delays  available,  GLONASS  satellite  position  transformed 

CGGTTS  GPS /GLONASS  DATA  FORMAT  VERSION  »  02 
REV  DATE  =  1996-10-20 

RCVR  =  3S  Navigation,  R-100/30,  LI  GPS  12  CH,  L1/L2  GLONASS  2  CH,  S/N  00020  Rev  004  1996-10-01 
CH  -  7  (GPS)  ,  7  (GLONASS) 

IMS  =  R-100/30 
LAB  =  33 

X  -  -2473157.78  m  (GPS , GLONASS) 

Y  =  -4706094.09  m  (GPS , GLONASS) 

Z  =  +3512042.48  m  (GPS , GLONASS) 

FRAME  =  ITRF,  PZ-90->ITRF  Dx  *  0.0  »,  Dy  =  0.0  m,  Dz  -  4.0  a,  ds  «  0.0,  RX  =  0.0,  Ry  ■  0.0,  Rz  ■  -0.000003 
COMMENTS  »  NO  COMMENTS 

INT  DLY  =  1366.0  ns  (GPS),  1312.0  ns  (GLONASS) 

CAB  DLY  =  100.0  ns  (GPS),  105.0  ns  (GLONASS) 

REF  DLY  =  0.0  ns 
REF  =  3S 
CKSUM  a  86 


SAT 

CL 

MJD 

STTIME 

TRKL 

ELV 

AZTH 

REFSV 

SRSV 

REFSYS 

SRSYS 

DSG 

IOB 

MDTR 

SMDT 

MDIO 

SMDI 

MSIO  SMSI 

ISO 

FR 

HC 

FRC 

CK 

hhnnnss 

s 

ldg 

.ldg 

.  Ins 

.lps/s 

.Ins 

.  lps/s 

.  Ins 

.Ins. 

lps/i 

3 . Ins . lps/ s . Ins . lps/s 

.  Ins 

107 

34 

50367 

231000 

780 

273 

3287 

+903734 

+114 

+1906 

+69 

41 

9 

177 

-46 

218 

-34 

225  -10 

09 

21 

1 

L1C 

Cl 

107 

34 

50367 

232300 

180 

273 

3287 

+903764 

+105 

+1936 

+60 

42 

9 

156 

-33 

201 

-30 

189  -40 

20 

21 

1 

L1C 

B9 

9 

18 

50367 

232600 

780 

428 

2719 

+491057 

-63 

+2120 

-72 

29 

9 

119 

-8 

174 

-16 

9999  9999 

999 

0 

0 

L1C 

4A 

107 

18 

50367 

232600 

780 

348 

3257 

+903854 

+87 

+1926 

+41 

42 

9 

142 

-27 

188 

-28 

202  -30 

17 

21 

1 

L1C 

BF 

ANNEX  I 

A  Suggested  GPS  Format  Update  for  GPS/GLONASS 

This  is  a  suggested  update  of  the  CGGTTS  GPS  Data  Format  Version  01  as  published  in  [1], 
for  GPS/GLONASS,  with  suggested  name  CGGTTS  GPS/GLONASS  Data  Format  Version  02. 
Adopted  notations  are  the  same  as  for  Version  01. 

1.  File  header 

Line  1-3:  same  as  Version  01. 

Line  4:  “CH*  =  *"  NUMBER  OF  CHANNELS 

Number  of  receiver  channels  separately  for  GPS  and  GLONASS. 

As  many  columns  as  necessary. 

Line  5-6:  same  as  Version  01. 

Line  7-9:  same  as  Version  01,  but  “GPS  antenna”  should  be  replaced  by  “GPS/GLONASS 
antenna” 

Line  10:  Designation  of  the  reference  frames,  and  if  necessary  transformation  parameters 
between  GLONASS  and  GPS  frames. 

As  many  columns  as  necessary. 

Line  11:  same  as  Version  01. 

Line  12:  “INT’DLY*  =  •"  INTERNAL  DELAY  “*ns*(GPS),”  INTERNAL  DELAY 
“*ns*(GLO>” 

Internal  delays  entered  in  the  receiver  separately  for  GPS  and  GLONASS,  in  ns  and 
given  with  1  decimal. 

As  many  columns  as  necessary. 

Line  13:  “CAB’DLY*  =  •”  CABLE  DELAY  “*ns*(GPS>,”  CABLE  DELAY  “*ns*(GLO>” 
Delays  from  the  antenna  to  the  main  unit  including  delays  in  the  antenna  element,  filters, 
electronics  and  cable  length,  entered  in  the  receiver  separately  for  GPS  and  GLONASS, 
in  ns  and  given  with  1  decimal. 

As  many  columns  as  necessary. 

Line  14-17:  same  as  Version  01. 

2.  Line  header 

2.1  No  measured  ionospheric  delays  available 

For  no  ionospheric  measurements  available  line  header  update  is  as  follows: 

Line  18.1:  “SAT*CL**MJD”STTIME*TRKL*ELV*AZTH***REFSV******SRSV***** 
REFSYS****SRSYS**DSG*IOE*MDTR*SMDT*MDlO*SMDI*FR*HC*FRC*CK” 
The  acronyms  are  explained  in  Section  4  below.  113  columns. 

2.2  Measured  ionospheric  delays  available 

With  ionospheric  measurements  available  line  header  update  is  as  follows: 

Line  18.2:  “SAT*CL**M.TD**STTIME*TRKL*ELV*AZTH***REFSV******SRSV***" 
REFSYS****SRSYS**DSG*IOE*MDTR*SMDT*MDIO*SMDI*MSlO*SMSI*ISG* 
FR*HC*FRC*CK” 
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The  acronyms  are  explained  in  Section  4  below.  127  columns. 

3.  Unit  header 
Same  as  Version  01. 

4.  Data  line 

Line  20,  columns  1-3:  “123”  SAT  GPS  or  GLONASS  satellite  identification  number. 

a.  GPS  satellite  PRN  number,  1  to  38.  No  unit. 

b.  GLONASS  almanac  slot  number  plus  100,  101  to  124.  No  unit. 

Line  20,  columns  4-53:  same  as  Version  01. 

Line  20,  columns  54-64:  “  + 1234567890”  REFSYS 

Title  changed  from  “  REFGPS”  to  indicate  reference  to  either  constellation. 

Data  content  same  as  Version  01. 

Line  20,  column  65:  same  as  Version  01. 

Line  20,  columns  66-71:  “+ 12345”  SRSYS 

Title  changed  from  “  SRGPS”  to  indicate  slope  for  either  constellation. 

Data  content  same  as  Version  01. 

Line  20,  columns  72-101:  same  as  Version  01. 

4-1  No  measured  ionospheric  delays  available. 

Line  20,  columns  102-103:  “12”  FR 

GLONASS  transmission  frequency  channel  number.  1  to  24.  For  GPS  set  to  0.  No 
unit. 

Line  20,  column  104:  space,  ASCII  value  20  (hexadecimal). 

One  20,  columns  105-106:  “12”  HC 

Receiver  hardware  channel  number.  0  to  99.  No  unit. 

Line  20,  column  107:  space,  ASCII  value  20  (hexadecimal). 

Line  20,  columns  108-110:  “123”  FRC 

Frequency  and  Code  type  used  for  pseudo-range  measurement,  where: 

L1C  -  LI  C/A  code, 

LIP  -  LI  P  code, 

L2C  -  L2  C/A  code  (GLONASS  future  capability), 

L2P  -  L2  P  code. 

Line  20,  column  111:  space,  ASCII  value  20  (hexadecimal). 

Line  20,  columns  112-113:  “12”  CK 

Data  line  check-sum  for  columns  1  to  111.  Check-sum  algorithm  as  defined  for  Version 

01. 

Line  20,  columns  114-140:  “123456789012345678901234567” 

Optional  comments  on  the  data  line,  constituted  of  characters  which  are  not  included  in 
the  line  check-sum  CK. 

4-2  Measured  ionospheric  delays  available 
Line  20,  columns  102-115:  same  as  Version  01. 


Line  20,  columns  116-117:  “12”  FR 

GLONASS  transmission  frequency  channel  number.  1  to  24.  For  GPS  set  to  0.  No 
unit. 

Line  20,  column  118:  space,  ASCII  value  20  (hexadecimal). 

Line  20,  columns  119-120:  “12”  HC 

Receiver  hardware  channel  number.  0  to  99.  No  unit. 

Line  20,  column  121:  space,  ASCII  value  20  (hexadecimal). 

Line  20,  columns  122-124:  “123”  FRC 

Frequency  and  Code  type  used  for  pseudo-range  measurement,  where: 

L1C  -  LI  C/A  code, 

LIP  -  LI  P  code, 

L2C  -  L2  C/A  code  (GLONASS  future  capability), 

L2P  -  L2  P  code. 

Line  20,  column  125:  space,  ASCII  value  20  (hexadecimal). 

Line  20,  columns  126-127:  “12”  CK  i 

Data  line  check-sum  for  columns  1  to  125.  Check-sum  algorithm  as  defined  for  Version  ] 

01. 

Line  20,  columns  128-140:  “1234567890123” 

Optional  comments  on  the  data  line,  constitued  of  characters  which  are  not  included  in  J 

the  line  check-sum  CK.  « 
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